Chapitre 17 [dev] Pratiques, trucs et astuces de code avec R

17.1 Gestion des encodages

Difficile de rédiger la documentation en français lorsqu’on code un package R parce que l’encodage non-ASCII n’est pas accepté par les check().

• Un moyen d’esquiver le problème est d’écrire la doc apparaissant dans l’index sans les accents
• Chosisissez le mode de transformation de vos codes avec de l’ASCII grâce à {stringi}

# Avec les accents
stringi::stri_escape_unicode("#' @param les étoiles dü joùr")
if(missing("big_mark")) {big_mark <- "\u202f"}
# Sans les accents en ASCII
stringi::stri_trans_general("#' @param les étoiles dü joùr", id = "Latin-ASCII")

• Une autre solution a été proposée pour COGugaison pour nettoyer tous les codes : https://github.com/antuki/COGugaison/pull/5

17.2 Tester la compilation de vignette pendant son développement

Pour économiser les étapes d’installation du package pour chaque fonction créée, vous pouvez utiliser la méthode du load_all().
Cette fonction permet de charger dans l’environnement global, toutes les fonctions du package en cours de développement.

Soyez prudent, lorsque vous êtes dans une vignette, selon que vous exécuter le code directement dans la console ou dans la vignette, la racine du projet n’est pas au même endroit. Ainsi, en haut de votre vignette, dans le chunk de setup, vous pouvez avoir ces lignes de commandes

# A décommenter avant les check() d'envoyer sur le serveur
# A commenter pendant la phase de création de la vignette
library(propre.rpls) 
# A commenter avant les check() d'envoyer sur le serveur
# A utiliser pendant la phase de création de la vignette
pkgload::load_all(path = "..", export_all = FALSE) # En mode notebook et en Knit en clic bouton
# pkgload::load_all(export_all = FALSE) # En mode exécution du code dans la console

17.3 Les notes sur les globalVariables à cause du {tidyverse}

Ces notes apparaissent parce que le {tidyverse} utilise la “Non Standard Evaluation” (NSE). Vous avez remarqué que les noms des variables, dans la plupart des fonctions du {tidyverse} sont utilisées sans parenthèses. Les tests du check() pensent que ce sont des variables classiques qui devraient être déclarées quelque part, mais il ne les trouve pas. Et pour cause, elles ne sont pas indépendantes du jeu de données auquel elles appartiennent.

Il y a deux manières de gérer ces variables globales lorsqu’on écrit des fonctions avec le {tidyverse} : montrer qu’elles sont dans une table de données avec .data[[var]] ou bien les déclarer, une par une dans un fichier .R à part avec globalVariables().

Par exemple le script ci-dessous dans un Rmd classique :

iris %>% 
  select(Species)

Avec la méthode .data dans une fonction devient :

#' My selection
#'
#' @param data.frame to select 'Species' from
#' @importFrom dplyr select
#' @importFrom magrittr %>%
mon_select <- function(x) {
  iris %>% 
    select(.data[["Species"]])
}

Note: Il vaut mieux utiliser data[["var"]] parce que le $ fait de la “correspondance floue”. Si votre liste / data.frame c’est :

data <- list(bonjour = 12, tata = 30)

Il est possible de récupérer la valeur de bonjour avec data$bon, nul besoin de l’écrire en entier. Si vous avez un code avec des noms de colonnes qui n’existent plus, plus tard, vous risquez de ne pas voir qu’il ne devrait plus fonctionner parce qu’il fait une correspondance avec une autre colonne.

Avec la méthode globalVariables et une fonction devient :

#' My selection
#'
#' @param data.frame to select 'Species' from
#' @importFrom dplyr select
#' @importFrom magrittr %>%
mon_select <- function(x) {
  iris %>% 
    select(Species)
}

# Dans un script à part, nommé 'globals.R':
globalVariables(c("Species"))

Pour créer le fichier avec globalVariables, vous pouvez utiliser le package {checkhelper} disponible sur GitHub seulement. Il fait passer le check() du package, donc ça prend un peu de temps. Il récupère la liste des notes sur les globalVariables et fait une proposition pour le script à mettre dans globals.R.

# remotes::install_github("thinkr-open/checkhelper")
# Ajouter dans le dev_history
globals <- get_no_visible(quiet = TRUE)
print_globals(globals)

La recommandation étant de lister les variables globales par fonction, quitte à ce qu’il y ait des répétitions. De cette façon, si vous modifiez une fonction, vous pouvez redéfinir quelles variables globales ajouter ou retirer. Dans notre exemple ci-dessus, le fichier globals.R ressemblerait à celui-ci :

globalVariables(c(unique(
  # mon_select:
  "Species"
)))

17.4 Les choix en data visualisation

Toutes les représentations graphiques ne sont pas adaptées aux données que vous voulez présenter. Par ailleurs, ce n’est pas parce qu’on a toujours fait comme ça, que c’est une bonne manière de faire. En tant qu’analystes de données, il nous appartient de proposer et expliquer les alternatives de représentations des données et de choisir des représentations qui ne biaisent pas l’interprétation des données.
Vous pouvez lire le contenu de cette présentation d’Arthur Katossky qui parle de perception visuelle et aussi de cartes. Vous pouvez vérifier dans la liste des Caveats du site “data-to-viz” les recommandations quand aux graphiques qui biaisent la perception. D’ailleurs, vous pouvez utiliser l’explorateur de visualisation de ce même site pour choisir une visualisation adaptée au type des données que vous voulez représenter. Enfin, dans notre article “Comment se passer d’un barbarplot”, nous vous expliquons pourquoi et comment éviter ces “barbarplot” ou “dynamite plot”.

17.5 git en ligne de commande dans le Terminal RStudio

Il peut être pratique d’utiliser git en ligne de commande pour régler des soucis importants. Dans le Terminal RStudio, lorsque vous êtes dans un projet versionné avec git, vous avez la possibilité de taper les commandes git directement.

17.5.1 Vi par défaut

Si vous avec des messages de commit à gérer et que vous ne changez pas votre configuration, vous allez être confrontés à l’interface “Vi”. C’est un éditeur de texte en ligne de commande. Il ne réagit pas aux mêmes raccourcis clavier qu’un éditeur de texte classiques. Il nécessite des commandes clavier pour s’utiliser. Voici quelques outils pour un message de commit :

• Créer un commit avec git commit
• Vous arrivez dans l’interface “Vi” qui vous permet de rédiger votre message de commit et les informations supplémentaires
  • N’utilisez pas la souris, mais uniquement les flèches du clavier pour vous déplacer
  • En descendant dans le fichier, vous verrez qu’il y a quelques informations que vous pouvez débloquer
• Pour pouvoir écrire dans ce fichier, vous devez activer le mode “Insertion” en appuyant sur le “i” comme Icare de votre clavier
• Vous pouvez ainsi rédiger votre titre de commit, passer une ligne avec “Entrée” et écrire les autres informations
• Rédiger en mode markdown, ce sera lisible et mis en forme sur l’interface GitLab
• Vous pouvez commenter des lignes avec dièse # en premier, elle n’apparaitront pas dans le message de commit
  • Vous pouvez aussi décommenter les lignes proposées par votre utilitaire git
• Sortez du mode “Insertion” en appuyant sur la touche “Echap” ou “Esc” de votre clavier
• Enregistrez le commit en tapant sur les deux touches :, x de votre clavier, puis “Entrée”
• Le message de commit est sauvé
• Si vous voulez quitter précipitamment ce fichier, sans enregistrer, assurez-vous de ne pas être en mode “Insertion”, en appuyant sur “Esc”/“Echap”, puis forcer la sortie sans enregistrer avec les trois touches :, q, !, puis “Entrée”

17.5.2 Nano pour plus d’aisance

Si vous souhaitez un éditeur de texte plus souple que Vi, vous pouvez vous orienter vers Nano. Pour cela, vous devez configurer cet éditeur par défaut avec git en tapant les lignes suivantes dans le Terminal RStudio :

git config --global core.editor "nano"

Il ne réagit pas aux mêmes raccourcis clavier qu’un éditeur de texte classiques. Il nécessite des commandes clavier pour s’utiliser. Voici quelques outils pour un message de commit : - Créer un commit avec git commit - Vous arrivez dans l’interface “Nano” qui vous permet de rédiger votre message de commit et les informations supplémentaires + N’utilisez pas la souris, mais uniquement les flèches du clavier pour déplacer votre curseur + Vous pouvez écrire directement où vous voulez - Vous pouvez ainsi rédiger votre titre de commit, passer une ligne avec “Entrée” et écrire les autres informations - Rédiger en mode markdown, ce sera lisible et mis en forme sur l’interface GitLab - Vous pouvez commenter des lignes avec dièse # en premier, elle n’apparaitront pas dans le message de commit + Vous pouvez aussi décommenter les lignes proposées par votre utilitaire git - Enregistrez le commit en tapant sur les deux touches CTRL + x de votre clavier, puis taper YES et Entrée pour sauvegarder - Le message de commit est sauvé - Si vous voulez quitter précipitamment ce fichier, sans enregistrer, CTRL +X puis taper NO et Entrée pour quitter